| 我的 Kafka 旅程 | 您所在的位置：网站首页 › ACL配置 › 我的 Kafka 旅程 |
我的 Kafka 旅程
|
系列目录 我的 Kafka 旅程 - 概念 · 特点 · 组成 · 模式 · 应用 我的 Kafka 旅程 - Linux下的安装 · 基础命令 · 集群 我的 Kafka 旅程 - Producer · 生产者线程 · 分区策略 · Sender线程 我的 Kafka 旅程 - Broker · 分区与副本 · ISR同步 · 应答机制 · 分区再平衡 · 节点选举 我的 Kafka 旅程 - 文件存储机制 · Segment文件 · 稀疏索引 · 数据清理 我的 Kafka 旅程 - Consumer · Offset · 消费组 · 组内再平衡 · 性能优化 我的 Kafka 旅程 - 参数优化 · 性能调优 · 压力测试 我的 Kafka 旅程 - SASL+ACL 认证授权 · 配置 · 创建账号 · 用户授权 · 应用接入本文基于 Kafka 3.5 的 KRaft 模式来阐述为开发环境准备的单机版 Broker + Controller 关于KRaft模式，目前它还不是特别稳定成熟，还不能完全替代ZK的角色，正如官网如下所说： 默认的 Kafka 不受认证约束，可不用账号就可以连接到服务，也就是默认的 PLAIN 方式，不需要认证；配置了 SASL 认证之后，连接Kafka只能用凭证连接登录。 SASL 支持的认证方式有多种：GSSAPI,PLAIN,SCRAM-SHA-256,SCRAM-SHA-512,OAUTHBEARER；其中 GSSAPI / OAUTHBEARER 都需要额外的独立服务，显得麻烦。那本文讲述的是比较简单的 SASL_PLAINTEXT 方式，认证机制统一为：SCRAM-SHA-512，ACL/SCRAM机制可追加新用户并授权到TOPIC。 那么基于 SASL+PLAINTEXT+ACL+SCRAM 的认证模式，本文涵盖的内容为： 配置服务端的认证模式 命令行创建新账号 授权账号到Topic的生产/消费权限 命令行凭证接入样例 客户端凭证接入样例作者：[Sol·wang] - 博客园，原文出处：https://www.cnblogs.com/Sol-wang/ 一、创建新用户所以在不受认证约束的默认情况下，默认支持SCRAM；启动后，使用 kafka-configs.sh，可以在 Kafka 中创建新用户： 如何首次启动 Kafka 参考：KRaft 模式启动 # 创建用户 bin/kafka-configs.sh --bootstrap-server {host}:9092 --alter \ --entity-type users --entity-name {u-name} --add-config 'SCRAM-SHA-512=[password={user-password}]' # 查看所有用户 bin/kafka-configs.sh --bootstrap-server {host}:9092 --describe --entity-type users # 查看指定用户 bin/kafka-configs.sh --bootstrap-server {host}:9092 --describe --entity-type users --entity-name {u-name}假设以上创建了 admin 的账号，后续继续使用此账号。 为什么要先创建一个账号 默认在没有账号的情况下，后续的认证授权生效后，用谁来连接到 Kafka 创建用户呢？？当然是先有一个管理员账号的存在，如上创建的账号，就假设以上创建的账号为管理员 admin。 用户的分类 - 超级管理员：对Kafka 的管理 - 写入Topic：用于生产端的接入 - 读取Topic：用于消费端的接入 二、Broker认证授权配置接下来，让创建的用户起作用，就要配置认证授权机制，Kafka-KRaft 的默认认证机制为 PLAINTEXT，不需要凭证的；本文目标机制为 SASL_PLAINTEXT，这就需要凭证(账号等)了。 2.1 简单方式在默认的基础上 Brokerconfig/kraft/server.properties配置如下： ######## 认证配置 listeners=SASL_PLAINTEXT://:9092,CONTROLLER://:9093 # 定义三种通讯的认证模式，注释掉advertised.listeners inter.broker.listener.name=SASL_PLAINTEXT # 内部节点通讯认证名称，注释掉security.inter.broker.protocol ######## 认证机制 配置 sasl.enabled.mechanisms=SCRAM-SHA-512 # SASL 启用的认证机制 sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512 # Broker节点之间的认证机制用已启用的机制 ######## ACL 账号限制 配置 super.users=User:admin # 定义超级管理员 allow.everyone.if.no.acl.found=true # true：支持账号黑名单；false：支持账号白名单 # ACL 对于 KRaft 模式的授权方式(类名) authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer这样的配置，使得三种通讯的认证机制统一为SASL_PLAINTEXT；那么就可以直接跳到[2.3 章节]继续配置了。 但如果你想深究这块更细的配置，请继续下章节内容，以细化这里的简单配置。 2.2 具体方式假如：对外认证机制用 SASL_PLAINTEXT，内部认证机制用 PLAINTEXT。 关于 Kafka 中的这三种通讯，这里计划这样做： 通讯 作用 认证机制 自定义别名 客户端(生产/消费) 与 Broker 之间的通讯 对外的 计划用 SASL_PLAINTEXT CLIENT Broker节点 与 Broker节点 之间的数据通讯 内部的 计划用 PLAINTEXT BROKER 集群(KRaft)管理 Broker 节点 产生的控制器通讯 内部的 计划用 PLAINTEXT CONTROLLER上述三种通讯分别起了自定义别名，接下来会在配置项之间相互引用定义的名称。 在配置 Borker 前，如果想理解各项配置含义，需要弄清以下几点。 首先，listener.security.protocol.map中SASL支持的通讯协议有哪几种：{别名}:{协议} SSL SASL_SSL PLAINTEXT SASL_PLAINTEXT（本文选择）其次，既然需要三种通讯，就在listeners中配置需要的通讯端口：{别名}://:{端口号} 客户端：9092 控制器：9093 Broker：9091最后，SASL 的认证机制有哪几种： GSSAPI PLAIN SCRAM-SHA-256 SCRAM-SHA-512（本文选择） OAUTHBEARER理清以上几点后，Broker 需要做以下几点，步骤包含层次及别名引用关系： 在listener.security.protocol.map中追加定义，用新起的通讯别名+协议，新别名供后续配置引用 在listeners中分别配置要监听的三种通讯的端口，名称引用中的通讯别名 CLIENT, BROKER, CONTROLLER 在inter.broker.listener.name上配置 Broker 之间的通讯，引用中的通讯别名 BROKER 在controller.listener.names上配置 集群管理节点的通讯，引用中的通讯别名 CONTROLLER 在sasl.enabled.mechanisms配置SASL启用的认证机制PLAINTEXTSCRAM-SHA-512 在sasl.mechanism.inter.broker.protocol配置内部Broker间的认证机制PLAINTEXT 配置 ACL 的授权，后续计划用 ACL 方式授权到指定的TOPICBroker 的配置效果，在config/kraft/server.properties配置如下： ######## 认证方式(内/外) 配置 # 追加的三个自定义名称 CONTROLLER / BROKER / CLIENT 及各自的认证模式（原有的配置略写...） # CONTROLLER 是默认存在的，其实仅追加了两个 listener.security.protocol.map=CONTROLLER:PLAINTEXT,BROKER:PLAINTEXT,CLIENT:SASL_PLAINTEXT,... listeners=CLIENT://:9092,CONTROLLER://:9093,BROKER://:9091 # 引用上一行的名称，定义三种通讯的认证模式及端口 advertised.listeners=CLIENT://{host}:9092,BROKER://{host}:9091 # 引用上一行的名称，定义本机对外通讯认证/IP/端口 inter.broker.listener.name=BROKER # 引用上一行的名称，定义内部 Broker 间的通讯认证 #security.inter.broker.protocol=BROKER # 内部通讯安全协议（不配置就用上一行代替） ######## 认证机制 配置 sasl.enabled.mechanisms=SCRAM-SHA-512,PLAINTEXT # SASL 启用的认证机制 sasl.mechanism.inter.broker.protocol=PLAINTEXT # Broker节点之间的认证机制用已启用的机制 ######## ACL 账号限制 配置 super.users=User:admin # 定义超级管理员 allow.everyone.if.no.acl.found=true # true：支持账号黑名单；false：支持账号白名单 # ACL 对于 KRaft 模式的授权方式(类名) authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer配置总结：以上用到的三种通讯，各有各的通讯端口和认证机制： 对外用 SASL_PLAINTEXT / 9092 内部集群管理用 PLAINTEXT / 9093 内部数据同步用 PLAINTEXT / 9091 2.3 配置 Broker 的凭证文件配置了 SASL_PLAINTEXT 方式，就需要凭证文件；假设之前已经创建了用户 admin/*****，并且已配置为超级管理员。 为 Broker 配置 JAAS 文件，假设创建名称为 broker-jaas 的文件，内容如下： KafkaServer { org.apache.kafka.common.security.scram.ScramLoginModule required username="admin" password="***"; };再将 Broker 的 JAAS 文件配置到环境变量 编辑bin/kafka-server-start.sh追加行： export KAFKA_OPTS=" -Djava.security.auth.login.config={Path}/broker-jaas"JAAS Java Authentication and Authorization Service这里我们把 JAAS 称为凭证文件，任何连接到 Broker 都要附上对应的JAAS文件，以示身份。 重启 Kafka 服务，使其配置生效。此时，只能用定义了的超级管理员来连接操作 Kafka。连接需要的用户凭证于下节内容。 非首次运行，Kafka可能不会识别listener...map中新配置的别名，这跟log.dirs的文件有关，或还原或动态修改配置命令：bin/kafka-configs.sh --bootstrap-server {host}:9092 \ --entity-type brokers --entity-name {broker-id} \ --alter --add-config listener.security.protocol.map=... 三、命令行中的凭证假设之前已经创建了用户 admin/*****，并且已配置为超级管理员。 3.1 配置 Client 的凭证文件为命令行模式创建此用户的凭证文件，这里命名为 admin-user-jaas 保存起来。例如 admin 用户凭证内容如下： security.protocol=SASL_PLAINTEXT sasl.mechanism=SCRAM-SHA-512 sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="admin" password="*****";命令行模式，用凭证连接 Kafka 服务： 之后的每一步操作，都要带上用户凭证文件，假设用超级用户 admin 继续创建新用户的场景： bin/kafka-configs.sh --bootstrap-server {host}:9092 \ --alter --add-config 'SCRAM-SHA-512=[password={user-password}]' \ --entity-type users --entity-name {new-user-name} --command-config admin-user-jaas与之前不同的是多了--command-config admin-user-jaas 也就是admin用户的凭证信息。这时若不带凭证信息会提示 disconnected。 四、ACL授权用户到TOPIC用户创建好了，接下来要为用户授权到指定的 Topic 了，并指定权限。 4.1 按端授权通常生产端的授权也就是写入权限，那么消费端的授权也就是读取权限。 # 授权用户到指定 topic 的生产端(写入)权限 # --allow-principal：指定用户 # --topic {topic-name}：指定某个主题 # --producer：指定为(生产端的)写入权限 bin/kafka-acls.sh --bootstrap-server {host}:9092 --add --producer \ --allow-principal User:{user-name} --topic {topic-name} --command-config {admin-jaas} # # 授权用户到指定 topic 的消费端(读取)权限 # --allow-principal：指定用户 # --topic {topic-name}：指定某个主题 # --consumer：指定为(消费端的)读取权限 # --group {topic-group-name}：必须的消费组归属 bin/kafka-acls.sh --bootstrap-server {host}:9092 --add --consumer \ --allow-principal User:{user-name} --topic {topic-name} --group {topic-group-name} --command-config {jaas-name}以生产端为例，自动拥有[查看/写入/创建]权限：
先来看看 ACL 支持的权限有哪些：DescribeDescribeConfigsAlterIdempotentWriteReadDeleteCreateClusterActionAllWriteAlterConfigsCreateTokensDescribeTokens 按[读取/写入]授权案例： # 授权用户到指定 topic 的指定(create/read/write/describe)权限 # --allow-principal：指定多个用户 # --topic {topic-name}：指定某个主题 bin/kafka-acls.sh --bootstrap-server {host}:9092 \ --add \ --allow-principal User:{user1-name} \ --allow-principal User:{user2-name} \ --operation read \ --operation write \ --topic {topic-name} --command-config {admin-jaas}
随着业务不断的增长，创建更多的账号并授权到各个TOPIC使用。 4.3 其它授权管理以上都是以添加权限为主，除此之外，还有更多的操作方式，以下仅列出了 必要的/常用的 供参考： # 加入黑名单 (add deny-principal) bin/kafka-acls.sh --bootstrap-server {host}:9092 --add --deny-principal User:{u-name} --topic {t-name} --command-config {admin-jaas} # 加入白名单（add allow-principal）也就是上述的授权方式 bin/kafka-acls.sh --bootstrap-server {host}:9092 --add --allow-principal User:{u-name} --topic {t-name} --command-config {admin-jaas} # 查看已授权（all）不限[用户/主题] bin/kafka-acls.sh --bootstrap-server {host}:9092 --list --operation all --command-config admin-jaas # 查看权限（list）从主题查看权限 bin/kafka-acls.sh --bootstrap-server {host}:9092 --list --topic {t-name} --command-config admin-jaas # 移除权限（remove allow-principal） bin/kafka-acls.sh --bootstrap-server {host}:9092 --remove --allow-principal User:{u-name} --topic {t-name} --command-config {admin-jaas} 五、命令行用凭证接入所有的用户凭证文件JAAS都相同，只不过账号密码不同，同样的为客户端用户创建一个凭证文件。 跟 admin-user-jaas 文件一样，创建各自账号的JAAS凭证文件后，这里是生产端/消费端的命令行接入案例： # 生产端 用户凭证 连接到 Kafka # --producer.config {用户凭证文件} bin/kafka-console-producer.sh --bootstrap-server {host}:9092 --topic {topic-name} --producer.config upro-jaas # # 消费端 用户凭证 连接到 Kafka # --consumer.config {用户凭证文件} bin/kafka-console-consumer.sh --bootstrap-server {host}:9092 --topic {topic-name} --consumer.config ucsm-jaas --from-beginning 六、客户端应用凭证接入 6.1 .NET接入也就是把各账号凭证文件JAAS中的内容，移到客户端的配置类中，如下样例： var conf = new ConsumerConfig { GroupId = "test-cons-group", BootstrapServers = "192.168.56.101:9092", SaslUsername = "user-name", SaslPassword = "*********", SaslMechanism = SaslMechanism.ScramSha512, SecurityProtocol = SecurityProtocol.SaslPlaintext, SaslOauthbearerConfig = "org.apache.kafka.common.security.scram.ScramLoginModule" }; 6.2 可视化应用 Kafdrop 接入基于 Docker 的 SASL 接入方式： docker run -dit --name={容器名称} -p 9000:9000 \ -e KAFKA_BROKERCONNECT={kafka-node-host}:9092 \ -e KAFKA_PROPERTIES=$(cat kafka-admin-jaas | base64) \ obsidiandynamics/kafdropACL 权限列表，浏览曾经授权的用户权限：
基于 Docker 的 SASL 接入方式： docker run -dit --name={容器名称} -p 8080:8080 -e DYNAMIC_CONFIG_ENABLED=true provectuslabs/kafka-ui
ACL 权限列表，浏览曾经授权的用户权限：
|
下个版本(3.7)是ZK模式的最终版本，2024年计划推出4.0版本，届时仅支持 KRaft 模式。参考官方说明：KIP-833: Mark KRaft as Production Ready
【本文地址】